In this article, Pat Wright explains how to identify hidden risks in legacy applications before moving to the cloud. It features practical advice and guidance to avoid migration failures and surprises.
I have worked in very few companies that had applications that were only a few years old or were for greenfield projects. Typically, I find companies have applications that are more than five years old and have been running on the same hardware for many years more. For these applications, making a move to the cloud can be a challenge.
A DB migration I was recently involved with had an application that had been running on a local server, in the office, for over five years. It was in maintenance mode and didn’t really have much new code being written for it. It was critical to the company, and they were working on moving all the systems to the cloud. When it came time for the migration of this DB, however, a problem arose.
The problem with this migration, explained
We went through the same steps as we had done with others, but discovered that this particular application didn’t work without specific Database System Admin permissions. These permissions weren’t easy to set up in the cloud, so the first testing we did with the application failed.
We didn’t have any documentation around this, and none of the original engineers who understood what was needed from the application were around to help. Thankfully, in the end we were able to provide the proper permissions to the application to get it working in the cloud, using a temporary solution we created. This temporary solution allowed me to formulate the following advice to ensure the same doesn’t happen to you.
How we tackled the permissions issue
- Start a task force to list all applications and products that exist in the organization.
- Identify which applications are still needed and which ones need to change. This should be done in parallel with getting ready for the migration
- Track down documentation if possible. Introduce a process to create the documentation of the system as you migrate.
- Start building a test plan – or run a “quick test” with a copy of the application in the cloud – to find simple problems.
- Find genuine users of the application within your organization and make sure they do the testing. For example, somebody working in accounting is often the best person to test these items.
- Try to categorize the applications both by risk and by length of time for migration. This is important for future steps.
I hope this has helped you to find the skeletons in your systems and I am looking forward to helping you in the next article.
Cloud adoption is accelerating, but database migrations aren’t keeping pace. Find out why.
FAQs: Uncovering legacy system 'skeletons' before a cloud migration
1. What are “skeletons in the closet” in IT systems?
They are hidden dependencies, outdated configurations, or undocumented features in legacy applications that can cause issues during cloud migration.
2. Why do legacy applications fail during cloud migration?
They often rely on old permissions, hardware setups, or undocumented behavior that doesn’t translate easily to cloud environments.
3. How can I prepare legacy systems for cloud migration?
Audit all applications, review documentation, test early in the cloud, and involve real users in validation.
4. What is the first step in a successful cloud migration?
Create an inventory of all applications and identify which ones are still needed or require updates.
5. Why is documentation important in cloud migration?
Without documentation, critical system requirements may be missed, leading to delays or failures.
6. Who should test applications after migration?
Actual end users – often those who use the system daily – are best suited to identify real-world issues.
Load comments